Re: GLIB for a webserver
Em 13/12/2011 10:05, jcup...@gmail.com escreveu: That's not the problem, I think. All modern systems will let you allocate at least ~1.5 gb before refusing malloc, no matter how much memory you have or what other processes are doing. The trick is keeping the working set of the processes within physical memory and achieving that needs programs with some way to constrain their memuse. Well, this is something I can do without uch effort, I guess. Still not sure if it is enough, but for sure will implement. server could is something I would like to avoid at all costs, because the outside problems may be temporary. For instance, malloc could fail because other server running on the same machine is processing 1 million transactions. After they are processed, the resources are already available I don't think that can happen on any current system. malloc() won't fail (until you hit the per-process limit of 1.5gb), your machine will just start swapping horribly. Actually perhaps some versions of linux will start refusing malloc() as a way to try to escape from swap death? But that's very extreme behaviour and certainly won't happen in any normal circumstances. I saw a linux a process once because the machine load average was too high. In fact, I was thinking here if it pays the way to worry to much with this situation, as it is something that should happen ever. The system administrators should be able to deal with this situation. I will implement what is easier to do now, without considering this extremes. If someone starts to use the program and report this problem, I try to find a way to solve it. Thanks for the comments. Marcelo ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GLIB for a webserver
Hello! Sorry again for the delay to replay. I was thinking in monitor the server memory to not let it reach the maximum allowed by the OS, which seems to be the basic idea behind what you have said. Although I think it' s better than nothing, the problem is that other machines processes may allocate memory after me and then, when my process try to allocate just a byte, it would crash. The best solution I though until now is to pre allocate the needed memory. For instance, if there will be 100 threads running and each one could use 20k of memory, I will try to pre-allocate 100*20k of memory. Of course each thread might use a different amount, but I can at least try to offer something like that. Anyway, if everything fails, there will always be the possibility to restart. My job is try to avoid it the maximum I can. About the malloc failing being the same as being as good as dead, I kind of agree, but I think this should be up to the user to decide. An exit() in the server could is something I would like to avoid at all costs, because the outside problems may be temporary. For instance, malloc could fail because other server running on the same machine is processing 1 million transactions. After they are processed, the resources are already available and the server will be able t ressurect again :D Regards, Marcelo Valle. Em 11/12/2011 09:12, jcup...@gmail.com escreveu: Hi Marcelo, On 10 December 2011 23:05, Marcelo Elias Del Valle mvall...@gmail.com wrote: Imagine the following scenario: the application running on my web server spends 20k of memory for each concurrent request. If I have enough concurrent requests in a way it will consume more memory than, let's say, 2Gb available memory, the expected result would be to refuse new connections, not restart the application and all current requests being handle. I have 2p to offer on this question too. I use gobject as the basis for an image processing library that gets used on servers. It's not quite the same as your problem (and I'm sure it's much less complicated!) but I think there are some similarities. In my opinion, this is part of a general question of resource envelopes. There are many resources my library has to manage apart from memory: for example, it has to work with images comprised of many separate files, sometimes up to 5,000 files to make a single image. Many *nix systems have a limit of about 1,000 simultaneously open files, so my library has to keep track of open files and if a request comes in for a section of image not currently mapped, has to consider closing some old files before attempting to open a new one. It's not practical to track all memory allocations but my library does track pixel buffers. If total pixel buffer usage gets near to a limit set by the user it will start to free old buffers before creating new ones. It also tries to limit the number of simultaneous threads that can be active to a user-specified number. I've not really looked at GPU usage yet but I imagine there will have to be some logic to constrain that somehow as well. Anyway, in my opinion, something like a web or image server needs to be told a resource envelope it should try to run within and needs some internal mechanism to manage requests which might push the system outside that range. If you've got to the point where malloc() is failing, your server is already as good as dead, unfortunately. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GLIB for a webserver
I didn't know that, thanks! Em 11/12/2011 17:53, Stefan Sauer enso...@hora-obscura.de escreveu: On 12/08/2011 02:13 PM, Marcelo Elias Del Valle - SYSMAP SOLUTIONS - Claro MA-SP - wrote: Hello, I am planning to use glib to write a C application server. I just like the library philosophy a lot and that’s why it is my first choice. However, after searching the web for a while, I have found some critics, which I list bellow: - On Apache ARP project, they said they created it instead of using glib because the lack of IPC functions like memory mapping. - In some forums, people were complaining about the fact glib aborts when memory allocation fails, which is bad for a 24/7 running web server. There is also g_try_malloc() and friends. This is advisable to use, if you allocated memory based on a protocol fields you are receiving over the net. This way you can avoid e.g. trying to allocate 4GB and terminate and instead reject the request. Stefan I would like to know the opinion of those more experienced with glib. Do you recommend me to use it for writing a web server? I really would like to use glib for that and I was thinking in some workaround to avoid this problems, like find some portable way to get the system's free memory before allocating anything and implement IPC functions using posix directly, even using glib thread pools for threads inside a process. Anyway, glib's first intention was to be used by visual applications, which is not the case. Would I be going against glib philosophy trying to use it for something like a web server? Regards, Marcelo. Esta mensagem, incluindo seus eventuais anexos, pode conter informações confidenciais, de uso restrito e/ou legalmente protegidas. Se você recebeu esta mensagem por engano, não deve usar, copiar, divulgar, distribuir ou tomar qualquer atitude com base nestas informações. Solicitamos que você elimine a mensagem imediatamente de seu sistema e avise-nos, enviando uma mensagem diretamente para o remetente e para postmas...@claro.com.br. Todas as opiniões, conclusões ou informações contidas nesta mensagem somente serão consideradas como provenientes da Claro ou de suas subsidiárias quando efetivamente confirmadas, formalmente, por um de seus representantes legais, devidamente autorizados para tanto. -- Este mensaje, incluyendo sus eventuales archivos adjuntos, puede contener informaciones confidenciales, de uso restringido y/o legalmente protegidas. Si usted ha recibido este mensaje por error, no debe utilizar, copiar, divulgar, distribuir o tomar cualquier actitud basada en estas informaciones. Solicitamos la inmediata eliminación del mensaje de su sistema y el envío de un informe en forma directa al remitente y a postmas...@claro.com.br. Todas las opiniones, conclusiones o informaciones contenidas en este mensaje solamente serán consideradas como provenientes de Claro o de sus subsidiarias cuando sean efectivamente confirmadas, formalmente, a través de uno de sus representantes legales debidamente autorizados a tal fin. -- This message, including all attachments transmitted with it may include restricted, legally privileged, and/or confidential information. If you received this message by mistake or in error you are hereby notified that you must not use, publicize, copy, distribute, resend, or take any action based on the information contained in the message. We ask you to delete the message immediately from your system and advise us by sending a message directly ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GLIB for a webserver
Hi Marcelo, On 10 December 2011 23:05, Marcelo Elias Del Valle mvall...@gmail.com wrote: Imagine the following scenario: the application running on my web server spends 20k of memory for each concurrent request. If I have enough concurrent requests in a way it will consume more memory than, let's say, 2Gb available memory, the expected result would be to refuse new connections, not restart the application and all current requests being handle. I have 2p to offer on this question too. I use gobject as the basis for an image processing library that gets used on servers. It's not quite the same as your problem (and I'm sure it's much less complicated!) but I think there are some similarities. In my opinion, this is part of a general question of resource envelopes. There are many resources my library has to manage apart from memory: for example, it has to work with images comprised of many separate files, sometimes up to 5,000 files to make a single image. Many *nix systems have a limit of about 1,000 simultaneously open files, so my library has to keep track of open files and if a request comes in for a section of image not currently mapped, has to consider closing some old files before attempting to open a new one. It's not practical to track all memory allocations but my library does track pixel buffers. If total pixel buffer usage gets near to a limit set by the user it will start to free old buffers before creating new ones. It also tries to limit the number of simultaneous threads that can be active to a user-specified number. I've not really looked at GPU usage yet but I imagine there will have to be some logic to constrain that somehow as well. Anyway, in my opinion, something like a web or image server needs to be told a resource envelope it should try to run within and needs some internal mechanism to manage requests which might push the system outside that range. If you've got to the point where malloc() is failing, your server is already as good as dead, unfortunately. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GLIB for a webserver
On 12/08/2011 02:13 PM, Marcelo Elias Del Valle - SYSMAP SOLUTIONS - Claro MA-SP - wrote: Hello, I am planning to use glib to write a C application server. I just like the library philosophy a lot and that’s why it is my first choice. However, after searching the web for a while, I have found some critics, which I list bellow: - On Apache ARP project, they said they created it instead of using glib because the lack of IPC functions like memory mapping. - In some forums, people were complaining about the fact glib aborts when memory allocation fails, which is bad for a 24/7 running web server. There is also g_try_malloc() and friends. This is advisable to use, if you allocated memory based on a protocol fields you are receiving over the net. This way you can avoid e.g. trying to allocate 4GB and terminate and instead reject the request. Stefan I would like to know the opinion of those more experienced with glib. Do you recommend me to use it for writing a web server? I really would like to use glib for that and I was thinking in some workaround to avoid this problems, like find some portable way to get the system's free memory before allocating anything and implement IPC functions using posix directly, even using glib thread pools for threads inside a process. Anyway, glib's first intention was to be used by visual applications, which is not the case. Would I be going against glib philosophy trying to use it for something like a web server? Regards, Marcelo. Esta mensagem, incluindo seus eventuais anexos, pode conter informações confidenciais, de uso restrito e/ou legalmente protegidas. Se você recebeu esta mensagem por engano, não deve usar, copiar, divulgar, distribuir ou tomar qualquer atitude com base nestas informações. Solicitamos que você elimine a mensagem imediatamente de seu sistema e avise-nos, enviando uma mensagem diretamente para o remetente e para postmas...@claro.com.br. Todas as opiniões, conclusões ou informações contidas nesta mensagem somente serão consideradas como provenientes da Claro ou de suas subsidiárias quando efetivamente confirmadas, formalmente, por um de seus representantes legais, devidamente autorizados para tanto. -- Este mensaje, incluyendo sus eventuales archivos adjuntos, puede contener informaciones confidenciales, de uso restringido y/o legalmente protegidas. Si usted ha recibido este mensaje por error, no debe utilizar, copiar, divulgar, distribuir o tomar cualquier actitud basada en estas informaciones. Solicitamos la inmediata eliminación del mensaje de su sistema y el envío de un informe en forma directa al remitente y a postmas...@claro.com.br. Todas las opiniones, conclusiones o informaciones contenidas en este mensaje solamente serán consideradas como provenientes de Claro o de sus subsidiarias cuando sean efectivamente confirmadas, formalmente, a través de uno de sus representantes legales debidamente autorizados a tal fin. -- This message, including all attachments transmitted with it may include restricted, legally privileged, and/or confidential information. If you received this message by mistake or in error you are hereby notified that you must not use, publicize, copy, distribute, resend, or take any action based on the information contained in the message. We ask you to delete the message immediately from your system and advise us by sending a message directly ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GLIB for a webserver
Hello, Sorry for the delay to replay.. If you write applications which don't leak memory, then you probably won't have any problem. Also if your web server fails because it consumes too much memory, this also probably means that either your HW is not strong enough to support your web server or your web server is leaking memory, and in this last case having it fail and restarting it is IMHO quite a good idea (much better code than trying to handle failed memory allocations). Actually, I am going to be honest in saying that I don't totally agree to you. You are right in saying that more hardware is needed or that leaking memory shouldn't exist. However, when we talk about a web server, we are talking about an application that will use memory on a per request basis. Imagine the following scenario: the application running on my web server spends 20k of memory for each concurrent request. If I have enough concurrent requests in a way it will consume more memory than, let's say, 2Gb available memory, the expected result would be to refuse new connections, not restart the application and all current requests being handle. Agree? Anyway, let me just make a point clear, first of all: I didn't asked this expecting someone on the list to solve this problem and my interest is not to criticize glib either. Actually, I understand this problem exists and I am willing to (and want to) use glib anyway. My fear is that I start to use it and see the glib development going in a different path in future, for example: someone might change the lib design in future in a way it would serve each time less server side applications, to focus better on being a basis to graphical frontend. The main question I tried to ask (I am usually bad to express it well, sorry), is: what are the plans for glib? Do you thing it will be each time more an independent library, with general use purpose, or will it be something focused to gnome apps? I was reading about D-BUS, for example, as I was interested in ways to implement IPC using glib, but althought it is part of GIO, its intention is to serve only to desktop apps, isn't it? Please have a look at the LibSoup library, I've used it before for a small embedded web server (in Libgda's console's tool) and it worked quite well, but it really depends on what you want to do. Thanks again for the recommendation. I took a look and it seems an excelent library for what I want to do. However, I still need to read the docs in details, it was not clear to me how the lib deals with threads to service calls and if it supports blocking/non blocking service handling. But if it serves to me, it will be my first choice. I already entered the mailing list too! :D Regards, -- Marcelo Elias Del Valle http://mvalle.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GLIB for a webserver
Hello,
- On Apache ARP project, they said they created it instead of using
glib because the lack of IPC functions like memory mapping.
This makes no sense since they could use glib and also write mmap
functions...
Well, that's what I thought too. That's why I made the decision to
ask here if it would make sense.
- In some forums, people were complaining about the fact glib aborts
when memory allocation fails, which is bad for a 24/7 running web
server.
A robust Web server would probably have a framework that restarted
components as needed; Apache already does some of this with workers.
The main problem with memory allocation comes when someone else's
process is using all the memory.
My server code is too smal yet to compare, but it is being already
planned to do it. I start each application hosted by my server in a
different process, so I will be able to restart it if the process
segfaults or quits for some reason. But I think like this (please tell
me if you agree or not):
- If the server itself (my code) seg fault, so it should stop. I
should solve this by fixing my code, not by writting whatdog for it,
as I explained above;
- However, as you said, if someone elses code (like applications or
service plugins in my case) segfaults, my server should be able to
restart the applications as needed.
But I pay a price for it. As this is implemented with IPC and I
need multiple processes, I will spend more computer resources
(CPU/memory) to deal with it, to make it more reliable. Pays the way,
but I imagine it's where it will need more optimization.
If you are writing a new Web server (why?) glib is probably fine.
By this affirmation, I understand glib is not only a basis for
desktop app, right? Good! I will like to use it.
The reason why I am writting is a bit of Linus Torwalds fault. :D
After reading hundreds of messages on a GIT mailing list on a thread
he started (http://article.gmane.org/gmane.comp.version-control.git/57918),
I realized I agree with him. My intention is not exactly to write a
web server, but an application server, like JBoss
(http://www.jboss.org/), but in C. I use Java app servers on my
day-by-day work, but just because people pay me to do that. I _hate_
Java resource consumption and I think it should exist a FAST, easy to
use alternative in C.
It's my pet project, by now.
Don't fight it, though. There's no portable way to find the system's
free memory, and even if there were, it wouldn't help -
if (amount_of_memory amount_available) {
// imagine that after that test succeeds,
// your program happens to get swapped out,
// and another program allocates all of memory
allocate_memory(); // fails
}
You are right. I haven't thought about it.
So it's better to assume that things will fail. Robustness does not come
from avoiding failure - it comes from recovering from failure.
This paragraph made me think a lot (thanks for it!). I fully agree
with you if I think on others' processes, but talking about the server
itself... Need to think. Anyway, the fact glib exits when memory
allocation fails wouldn't stop me from using it. I am sure there is a
way of solving it, one way or another. Of course finding it will be a
bit hard... But will think carefully on what you've said.
For a Web server that may just mean restarting. Sure, some users will
have to reload Web pages; if that's actually a problem, use persistent
storage to record state.
In the case of my server, each request may result in an open
database connection and possibly a started transaction. Stop all
current transactions because the server is on its limit is something
that might happen, but I don't consider good. I can recover from that,
but finding a way of not letting that happen would be preferable.
Apache and IIS are fairly large codebases for a reason, though -- a
secure reliable production Web server would have a lot of catching up to
do.
Sure, but I have no intention of replacing it. I plan to let my
server work as an apache or NGinx plugin someday. My project is much
more like Phusion Passenger (http://www.modrails.com/) or JBoss, but
for C development.
Of course there will be a lot of catching up too, but differently
of these servers, that focus mostly on how to service something in a
reliable way, I want to focus on providing an easy to use API for the
application developer, as my server hosts applications. I would
provide services like message queueing, database connection pools,
load monitoring, etc.
Here is where I found the power of gnome would help me a lot. By
using the APIs provided by gnome, as GDA, GLib itself, GIO, etc., the
application developer would have a portable, powerful and easy to use
API at his/her disposal, to write server side apps and application
middleware.
Unless all these libs are supposed to be used only by desktop apps
and I shouldn't be trying to use it for middleware... :D
Re: GLIB for a webserver
On 8 December 2011 14:13, Marcelo Elias Del Valle - SYSMAP SOLUTIONS - Claro MA-SP - marcelo.va...@claro.com.br wrote: Hello, I am planning to use glib to write a C application server. I just like the library philosophy a lot and that’s why it is my first choice. However, after searching the web for a while, I have found some critics, which I list bellow: - On Apache ARP project, they said they created it instead of using glib because the lack of IPC functions like memory mapping. - In some forums, people were complaining about the fact glib aborts when memory allocation fails, which is bad for a 24/7 running web server. If you write applications which don't leak memory, then you probably won't have any problem. Also if your web server fails because it consumes too much memory, this also probably means that either your HW is not strong enough to support your web server or your web server is leaking memory, and in this last case having it fail and restarting it is IMHO quite a good idea (much better code than trying to handle failed memory allocations). I would like to know the opinion of those more experienced with glib. Do you recommend me to use it for writing a web server? Please have a look at the LibSoup library, I've used it before for a small embedded web server (in Libgda's console's tool) and it worked quite well, but it really depends on what you want to do. Regards, Vivien ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GLIB for a webserver
On Fri, 9 Dec 2011, Chris Vine wrote: On Thu, 8 Dec 2011 11:13:41 -0200 Marcelo Elias Del Valle - SYSMAP SOLUTIONS - Claro MA-SP - marcelo.va...@claro.com.br wrote: - In some forums, people were complaining about the fact glib aborts when memory allocation fails, which is bad for a 24/7 running web server. This particular criticism has little going for it. Modern operating systems use swap and memory over-commit, and there is pretty well nothing you can do once memory is exhausted, particularly if you are a long way up the call stack. [...] But still, a sane (or sanely configured) OS can tell when it receives a huge request for memory that it definitely cannot honor. In that case -- where memory is not currently exhausted -- it's much preferable if the app can report Can't do it to the user rather than aborting. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GLIB for a webserver
On Thu, 2011-12-08 at 11:13 -0200, Marcelo Elias Del Valle - SYSMAP
SOLUTIONS - Claro MA-SP - wrote:
- On Apache ARP project, they said they created it instead of using
glib because the lack of IPC functions like memory mapping.
This makes no sense since they could use glib and also write mmap
functions...
- In some forums, people were complaining about the fact glib aborts
when memory allocation fails, which is bad for a 24/7 running web
server.
A robust Web server would probably have a framework that restarted
components as needed; Apache already does some of this with workers.
The main problem with memory allocation comes when someone else's
process is using all the memory.
If you are writing a new Web server (why?) glib is probably fine.
Don't fight it, though. There's no portable way to find the system's
free memory, and even if there were, it wouldn't help -
if (amount_of_memory amount_available) {
// imagine that after that test succeeds,
// your program happens to get swapped out,
// and another program allocates all of memory
allocate_memory(); // fails
}
So it's better to assume that things will fail. Robustness does not come
from avoiding failure - it comes from recovering from failure.
For a Web server that may just mean restarting. Sure, some users will
have to reload Web pages; if that's actually a problem, use persistent
storage to record state.
Apache and IIS are fairly large codebases for a reason, though -- a
secure reliable production Web server would have a lot of catching up to
do.
But, it's fun writing Web servers :-)
Liam
--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
